Preview url: https://operational-data-standard-85--cal-itp-previews.netlify.app

Based on this #28 (comment) - what @skyqrose outlined in August

Notes:

• vehicles.txt and vehicle_categories.txt crib liberally from http://bit.ly/gtfs-vehicles. That proposal aligned with platform descriptions for GTFS-Pathways. I don't know the current status of that proposal. I included a baseline of fields; perhaps more should be included in this proposal.
• I considered whether to relate vehicle assignments to run_events.txt, but since mid-run events would never involve the change of a vehicle, this would have created more complexity.
• vehicle_assignments can map to trip_id or block_id. This is for cases where block_id is not universally supplied, perhaps because a GTFS feed follows the original usage of block_id - indicating allowed in-seat transfers.

Some internal discussion at Optibus:
Timon Kelter suggested that vehicle_categories sounds very abstract, but vehicle_types would be more natural and is descriptive. I agree. I had was cribbing from the GTFS-Vehicles proposal, but don't see a reason to keep this term. Will plan to change to vehicle_types.txt.
BTW, I have invited Optibus team to share more discussion here. So we'll expose a bit more deliberation that might otherwise have been internal :)

These are vehicle properties that Optibus currently exports in a non TODS format. Which properties should be included in TODS?

Vehicle properties example.xlsx

From the fields mentioned above, I would remove at least new_seminew, ecological, static_information, onboard_monitor, all *_display fields, all *_sound fields and consumption_meter.

To me, those look too undefined, covered by other attributes like emission already or just not needed for operational purposes.

I'm also very unsure about folding_system, ramp and kneeling. Given that we have wheelchair and lowered_floow already that looks like too many details on the same question.

@skyqrose @safrazier17 Can you help guide process here? Since I worked off the #81 branch, this has the rosters and employee assignments spec draft. Should I remove those changes?

Will we vote on the two PRs separately or together? Merge separately?

We've been discussing this internally at Optibus, including with some CAD/AVL partners. For the upcoming version, we propose a "least viable" approach:

• Remove vehicle_types.txt
• Scale vehicles.txt down to vehicle_id and license_plate

This removes speculative vehicle attributes. The CAD/AVL should be able to look up vehicle attributes stored in that system.

Thoughts/reactions?

That does remove the ability to assign a type of vehicle without assigning a specific vehicle, but that's probably fine if we're aiming for a least viable approach.

@skyqrose If we pass a version of this without vehicle types, I think the discussion was still useful, so thanks for the review and great comments. And if we do add in more vehicle attributes besides the ID and license plate, then bringing back in vehicle type seems useful.

Pre-vote checklist (@antrim)

• Remove vehicle_types.txt
• Remove vehicles.vehicle_type_id
• Remove vehicles.vehicle_description
• Remove vehicles.registration_date
• Remove vehicles.owner
• Edit description of vehicles.license_plate to account for its use as a more generic unique vehicle identifier
• Add vehicles.vehicle_label
• Remove vehicle_assignments.vehicle_type_id
• Edit vehicle_assignments.vehicle_id description to include note about roadmap plan to allow assignments to be made to groups of vehicles (a la vehicle type) rather than just to individual vehicles
• Add vehicle assignments examples
• Edit the PR description so that it includes an overview of proposed changes as they currently stand and the goal of the changes

VOTING PERIOD OPEN

Voting is open on this PR through 11:59:59 UTC on April 8 EDIT: April 15, 2025. This PR is one of 3 comprising the TODS 2.1 version proposal. The other PRs associated with the TODS 2.1 proposal are #80 and #87.

WHO IS ELIGIBLE TO VOTE

Any individual may vote as an ODS Contributor; in voting, Contributors are acknowledging and agreeing to the ODS Contributor Agreement and ODS Code of Conduct.

Issue Working Group members @BTollison, @jeffkessler-keolis, @skyqrose, @jfabi, @safrazier17, @antrim, @hodb are not eligible to vote on this proposal.

HOW TO VOTE

• A vote of support for this PR, comment "+1 [Individual or Organization Name]"
• To support the proposal with a minor correction, add one comment to the PR including both the correction and "+1 [Individual or Organization Name]"
• To vote for a substantial revision to the proposal, comment "-1 [Individual or Organization Name]" along with a brief description of what you believe needs to be substantially revised before the proposal can be adopted. NOTE: TODS governance requires that voters requesting substantial revision commit to working with the Issue Working Group to develop their recommended revision.

OUTCOMES

• At the end of the voting period, if the proposal has received at least THREE (3) +1 votes from stakeholders outside of the Issue Working Group and votes of "Support with Minor Correction" or "Substantial Revision," the proposal is immediately adopted.
• If the proposal receives one or more votes of "Support with Minor Correction," the Issue Working Group may decide whether to incorporate the recommended changes or to appeal to the Board for consideration of the necessity of the recommended changes.
  • If the issue working group or the Board determine that the minor changes should be incorporated into the proposal, the proposal shall be updated and the TODS community shall be notified of the updates. After a period of FOUR (4) business days, the proposal shall be adopted immediately unless valid objections to the minor changes are received. No new voting period is automatically initiated.
• If the proposal receives one or more votes of substantial changes, the author(s) of the recommended changes must commit to working with the issue working group to develop an alternative proposal that meets the need raised by the reviewer. The issue working group may appeal to the Board if they believe a recommended substantial change is without merit.
  • If a proposal is substantially changed, then a new voting period must be opened before the amended proposal can be adopted.
• If the proposal does not meet the minimum threshold for votes outside of the issue working group, the working group may appeal to the Board for a decision. The Board may vote to adopt the proposal or to require a new voting period.

+1 [Optibus]

[Sarah from Swiftly]
Apologies for raising questions so late during the voting period but I am not clear on who will be able to leverage this spec. In my experience, I have not seen agencies know vehicle assignments far enough ahead of time to put them in a data feed, but rather it is more common to figure out vehicle assignments day of. I would love to learn about real-world cases where this would be applicable to understand whether it makes sense to add scope to the spec. Thanks!

[Sarah from Swiftly] Apologies for raising questions so late during the voting period but I am not clear on who will be able to leverage this spec. In my experience, I have not seen agencies know vehicle assignments far enough ahead of time to put them in a data feed, but rather it is more common to figure out vehicle assignments day of. I would love to learn about real-world cases where this would be applicable to understand whether it makes sense to add scope to the spec. Thanks!

@sbindman Our intended use case is transmitting the vehicle assignments for the immediate next days (typically the next
1-3 days) into a CAD/AVL system. It's not so much about transmitting a long-term assignment plan, I'm not aware of such a use case in reality.

@evansiroky We did not consider historical data, for that it indeed will be better to use TIDES Trips Performed. It's about the assignments for the next few days only.

Apart from the use case of getting existing vehicle assignments into a CAD/AVL system, transmitting the assignments for the next day can also be used for charge management systems (battery-electric buses). That system needs to know which vehicles will enter/leave a depot in the next day so that they can plan the charging in the best possible way.

As with the rest of TODS, we did not have real-time use cases in mind here.

@timon-k thanks for the clarifications that TODS is intended as a "planned" dataset.

I will go ahead and vote a cautious +1 on behalf of Caltrans as I think the concept makes sense, but still wonder about how applicable this is in the field.

I think it would be great to clarify the timing and use cases. The GTFS specification notes that:

the published GTFS dataset should be valid for at least the next 7 days

This is somewhat in conflict with what you've mentioned as the immediate next days (typically the next 1-3 days) with TODS, but perhaps this is to be expected in whatever context this is being used.

I am neutral on PRs 85 and 87. In my eyes, vehicle and driver assignments are a different interface and data is updated on a different schedule, but I see that it can be useful.

+1 [San Francisco Bay Ferry]

Looks like trying this from my work computer yesterday didn't go through unfortunately, but +1 [CTA]

VOTING PERIOD CLOSED

The voting period for this proposal closed yesterday, April 15 at 11:59:59 UTC. The proposal received the following votes:

Support (3): @timon-k (Optibus), @evansiroky (Cal-ITP), @arthi-weta (WETA)
Support with minor correction (0): No votes recorded
Substantial Revision (0): No votes recorded

The proposal has met the threshold of support needed and passes.